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ABSTRACT 

Since 1974, ONES has been involved in geostationary 
satellites positioning. Among different entities 
participating in operations and their preparation, the 
Flight Dynamics Center (FDC) is in charge of 
performing the following tasks : 

- orbit determination, 

- attitude determination, 

- computation, monitoring and calibration of orbit 
maneuvers, 

- computation, monitoring and calibration of attitude 
maneuvers, 

* operational predictions. 

In order to fulfill this mission, the FDC receives 
telemetry from the satellite and localization 
measurements from ground stations (CNES, NASA, 
INTELSAT, ...). These data are processed by space 
dynamics programs integrated in MERCATOR system 
which is implanted on SUN workstations (UNIX O.S.). 

The main features of MERCATOR are redundancy, 
modularity and flexibility : 

- efficient, flexible and user friendly man/machine 
interface, 

- four identical SUN stations totally redundant linked in 
an Ethernet network. 

Each workstation can perform all the tasks from data 
acquisition to computation results dissemination 
through a video-network. 

A team of four engineers can handle the space mechanics 
aspects of a complete geostationary positioning from the 
injection on a transfer orbit to the final maneuvers in the 
station-keeping window. MERCATOR has been or is to 
be used for operations related to more than ten 
geostationary positionings. 

Initially developed for geostationary satellites, 
MERCATOR’S methodology was also used for satellite 
control centers and can be applied to a wide range of 
satellites and to the future manned missions. 


Keywords : 

Flight Dynamics, support system, man-machine 
interface, UNIX O.S., telemetry, maneuvers 


1. INTRODUCTION 

MERCATOR (MEthods and Realization for Control of 
the ATtitude and the ORbit of spacecraft) is a data 
processing system used by the Flight Dynamics Center 
(FDC), which is responsible for space mechanics aspects 
of geostationary satellite positionings (Launch and Early 
Operations Phases - LEOP) performed by CNES ground 
segment located in Toulouse Space Center. 





NOC : Network Operations Center (communications 
between the different CNES entities involved in the 
LEOP - video, voice loop, data flows - and with the 
ground stations all over the world) 

SCC : Satellite Control Center (telemetry processing, 
telecommands) 

FDC : Flight Dynamics Center (space mechanics 
aspects) 

OCC : Orbit Computation Center (in charge of stations 
designations : providing antenna pointing data - APD) 
MCR : Main Control Room (mission management) 

SSR : Spacecraft Specialists Room 

FDC has been involved in LEOP for 1 8 years : 

- 6 positionings between 1974 (Symphonie) and 1988 
(TDF 1), 

- 10 positionings performed with MERCATOR since 
1989 (TELE-X) until more recently, HISPASAT, in 
September 92. 
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In charge of the space mechanics aspects, this 
multimission entity, from the beginning of a project, 
performs the mission analysis studies, in order to define 
and verify the feasibility of positioning maneuvers 
strategies. Then, it develops the space mechanics 
applications since their conception up to the complete 
validation of the integrated system. Autonomous entity, 
it receives the satellite telemetry, and the localization 
measurements from ground stations via the Network 
Operation Center (HOC). Its results are transmitted to 
other entities via video pages. In addition to resolution 
methods for the various problems encountered during 
LEOP (space mechanics software), the FDC leans on a 
data processing system, efficient, flexible and reliable. 
MERCATOR is usually operated by four space 
mechanics experts. 

FDC is organized on two levels : 

- the data processing system named MERCATOR, 

- space mechanics applications, some of them muti- 
mission, others specific to the mission to achieve. 


2. OBJECTIVES OF MERCATOR 

MERCATOR was designed in 1986 with some ambitious 
objectives listed here below (Ref. 1). 

First, the data processing system must be simple. It must 
allow any operational user to have a complete 
representation of the system and to control it. 

Second, concerning the number of operating people, 
typically three people must be sufficient to perform the 
flight dynamics tasks related to a complete geostationary 
positioning. Operational constraints (operations 
duration, ...) lead to a four-people team in order to insure 
redundancy. 

Another objective is that the same system must apply to 
a wide variety of spacecraft. Adapting FDC from a 
previous to a new mission should consist in modification 
or replacement of elementary modules, either software 
or ASCII files of the data base (concept of tool box). As 
several FDC teams might prepare different LEOP 
simultaneously, FDC facilities have to allow different 
configurations and an easy and fast transposition from 
one to another. 

The workload corresponding to the implantation of a 
software must be negligible with respect to its 
specification, development and validation. 

The development must emphasize the assistance to the 
space dynamics experts, in nominal cases as well as in 
contingency cases. The interactive monitoring, graphical 
and diagnosis tools must allow the user to have a 
complete view of the occuring events through the 
available data and to extract as much information as 
possible from them, even if this information is not 
complete (example : first orbit diagnosis) and leads to 
rough evaluations. 


In contingency cases, the system must allow to insert 
additional data in reserve software without damaging 
nominal software. 

From the performance and security point of view, it 
should be possible to filter and condense data before 
treatment in order to eliminate erroneous data and to 
limit the treatment computation load. 

At the end, and these are constant preoccupations for 
any project, the development cost must be minimized ... 
and the probability of success must be ... maximal. 


3. ACHIEVEMENT OF THESE OBJECTIVES 
3.1 Hardware Choices 

Due to their qualities relative to computation power, 
ergonomy, reliability, cost, ..., UNIX based SUN 
workstations were chosen. 

The modular distributed architecture used for a LEOP is 
depicted on Fig. 2. It consists of four identical 
workstations SUN 4/330 (ST1, ST2, ST3 and ST4) linked 
by a local Ethernet network and two micro-computers 
(HP Vectra PCI and PC2) also connected to this network 
in order to handle the graphical video outputs. 

Three workstations are sufficient to perform the 
operations, the fourth one is only for hot redundancy. 

Each workstation hosts the same software and is 
equipped with : 

- central memory of 16 Mbytes, 

- bulk memory : one 699 Mbytes disk, 

- multiplexer : one ALM2 with 16 channels RS232, 

- 1 50 Mbytes streamer unit, 

- extension capability : 2 free slots. 


3.2 Software Choices 

MERCATOR data processing system can be described as 
a flight dynamics "support system", i. e. a software 
structure providing : 

- elementary functions (general communication facilities 
for external data interfaces, data preprocessing, system 
monitoring, time synchronization, ...), 

- shells and state of the art man-machine interface for 
implantation, modification and implementation of 
application software. 

This structure has been designed so as to minimize the 
integration effort, most of the work being concentrated 
on the tool itself. 

Moreover, the functions to be performed for different 
LEOP are similar: consequently, the principle of "a 
family of flight dynamics specific applications" has been 
preferred in order to minimize the adaptations of the 
tools from one mission to another. 
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Fig. 2 ; FDC Hardware Architecture 


3,2.1 Software architecture 

Two operating modes are proposed : 

. Implantation mode which corresponds to FDC 
preparation before the LEOP, with two aspects : 

-data base management, including classical functions 
such as creation, modification, suppression, control 
(consistency or completeness), printing, save, restore, 
list, ..., 

- implantation of applications offering functions such as 
creation, suppression, modification, control 
(completeness : control of the presence of necessary flies 
-or information-), consistency with data base (label, 
units), syntax, list, cross check. 

This mode provides complete security and reliability for 
the implanted applications and data. In addition to this 
security, great flexibility and simplicity are offered to the 
user. As an example, the time to implement any new 
flight dynamics piece of software in Mercator sytem is 
less than one day. 

. Operation mode used during LEOP, consisting in 
performing the positioning computations and operations 
in a user friendly and safe environment. 

Once the space mechanics applications are implanted in 
MERCATOR system, FDC can perform the following 
tasks : 


a) MERCATOR applications : 

-data acquisition, decommutation and preprocessing 
(telemetry and localization measurements), 

- system monitoring, 

- time initialization (simulated time) and 
synchronization (U. T.), t 

- various functionalities available to interpret 
phenomena and results : editions, interactive displays, 
deferred time executions, chaining of functions, filters on 
data, visualization and sorting of files, ...), 

b) Flight dynamics tasks : 

- real-time orbit determination, 

- real-time attitude determination, 

- computation, real-time monitoring and calibration of 
orbit and attitude maneuvers, 

-operational predictions (eclipses, stations RF 
visibilities, sensors visibilities, ...), 

The performances of the system naturally improve the 
quality of the man/machine interface. 

Moreover, the compatibility of MERCATOR system 
with UNIX functionalities and multi-windowing allows 
us to have at our disposal a great number of 
supplementary analysis possibilities. It has also to be 
noticed that nowadays, the applications (including 
mission analysis) are developed on SUN, so there is 
commonality in terms of work environment since the 
preliminary studies up to the operations. 
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The user can open several windows in parallel 
corresponding to simultaneous execution of different 
applications. 

The software configuration is identical for each 
workstation. The execution of the different applications 
is shared out among the workstations set up on the 
operational network. This sharing is governed by 
redundancy considerations and by the set of tasks to be 
done at the given time during the mission. 


3.2.2 Main functions of MERCATOR support system 

a) Data origin machine 

Telemetry and localization data are decommuted and 
preprocessed after acquisition and stored in both raw 
and preprocesed forms. This function is usually activated 
on one or two workstations (for redundancy purposes). 
The obtained data are available for any application 
module running on any operational workstation which 
can define what is its data origin machine. The advantage 
is that we can specialize the workstations according to 
the requirements at a given time, but as they are identical 
on both hardware and software point of view, this 
configuration can be modified very quickly (a few 
minutes) when the needs are changing or if there is a 
workstation failure. 

b) System monitoring 

The role of this task is to provide operator assistance to 
the operations. The main functions are : 

. process monitoring : 

- monitoring the running of the different processes 
activated, 

- monitoring the operating of the various resources 
(CPU, disks, memory, Ethernet bus, ...). 

- generating alarm detection and messages to inform 
the operator of any trouble in the progress of 
processing, 

-archiving ail the reports of investigations and 
monitoring in the Log Book ; 

. datation management for the application which allow 
us to perform simulations or replays in realistic and 
actual configurations of the positioning operations 
(simulation of the launch at a certain date, 
maneuvers, ...), synchronization with the U. T. provided 
by ONES atomic clock. 

c) Data base 

Information relative to spacecraft, ground stations and 
data shared by several applications are organized in a 
data base structure consisting in different ASCII files, the 
main ones being : 


. spacecraft technological file : 

- sensors location, oreintation, field of view, 
-actuators (apogee motor, thrusters, wheels) 
location, orientation, characteristics, 

- antenna patterns, frequencies, 

. decommutation table to extract binary values from the 
telemetry flow : 

- position in telemetry format, 

- occurences, 

- position of the first bit in the frame, and length, 

- relation with other parameters, 

... telemetry transfer functions to convert binary values 
into physical values, 

. ground stations file : 

- stations coordinates, 

- meteorological data, 

- equipment delays, 

- calibration data, 

. state file : 

- orbital elements, 

- mass/inertia data, 

- calibration coefficients, 

These are data computed by some applications and used 
by others. This file is organized so as to preserve the 
historical record of the positioning. For instance, when a 
new orbit is validated in the state file, a new occurence of 
the orbital elements is created : parameter label, value, 
occurence, date-time of the validation. 

d) TM processing 

From each telemetry frame of the raw data file, this 
process decommutes the concerned parameters, then 
stores them in a file which contains the physical values 
updated in near real time. The interest of this function 
quite classical in itself is in the definition of the 
parameters to be decommuted. 

They are defined in two ASCII files (decommutation 
table and transfer functions - see Data base). This 
approach has proved its ability to handle various types of 
satellite telemetry with a minimum time being spent to 
set the configuration of this process. 

e) Input/output data management 

There are several ways for the MERCATOR user to 
define the input data of an application. Each datum is 
defined by a label, a value and a unit. 

When opening the window relative to an application, 
there is usually a default configuration with : 

- default values, 

- values taken out from data base files or output files from 
other applications according to their label. 
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The user can change this configuration : 

- entering a new value, 

- changing the name of the file from which the 
information is extracted (there is an error message 
"I/O error" if the file does not exist), 


0 Chaining of tasks 

Applications processing telemetry or localization 
measurements can be made up of one, two or three 
modules. These programs can be executed separately or 
chained (pipe) with the possibility to store the 
intermediate processed How into a file (tee). 


-modifying the variable part of the label (the new 
complete label should exist in the corresponding file, 
otherwise there is an error message "non initialized 
value”), 

- getting a complete set of input data from a retrieval file 
created during a previous run of the application : "restore 
configuration" functionality. 

The same mechanism applies to the output data allowing 
the user to : 

- create a retrieval file containing input and output data 
(label, value) : "save configuration" functionality, 

- validate some data in data base or specific files with the 
same flexibility on the file names and labels. 

These various possibilities are very useful during 
operations and warrant security and consistency in the 
execution of the different applications, offering at the 
same time a great flexibility. 


flow 
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Fig. 3 - Tasks chaining 



Fig. 4 : Example of MERCATOR screen during operations 
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The application can be executed in three modes : 

- synchronized : real time on flow, 

- deferred : off-line replay, 

- taking up : starting at given time, then real time on flow 
when arriving at the end of the file. 

The advantage of this approach is its flexibility, allowing 
to run elementary or complete functionalities in different 
modes. 

g) Video distribution 

Results of FDC computations, monitorings, analyses are 
distributed to other entities via a video network in three 
forms : 

-static alphanumerical pages such as maneuver pages 
including telecommands to be sent to the spacecraft, 

-dynamical alphanumerical pages such as real time 
display of orbital elements or telemetry parameters, 

- graphical displays on telemetry parameters, results of 
telemetry processing. 

These displays are defined in ASCII files prepared in 
advance but which can easily be modified in real time : it 
is thus possible to modify the scale of a graphical display 
without interrupting the application execution. 

For more complete information about the results of FDC 
applications, formatted files can be printed (with 
possible filter). 


CONCLUSION 

Designed and developped since 1986, MERCATOR data 
processing system was validated during TDF 1 LEOP 
(1988) and operationaly operated for the first time in 
1989 (TELE-X). Since then, it was successfully used for 
ten positioning including : 

- two LEOP being performed simultaneously (a second 
hardware configuration was settled for that purpose): 
INMARSAT-2 F3/TELECOM 2-A in December 1991 
and INMARSAT-2 F4/TELECOM 2-B in April 92, 

- a LEOP prepared and succesffully performed in a very 
short time (8 months to be compared to a usual 
preparation of about 18 months): ARABSAT 1-C in 
Februar 92, 

-a LEOP performed from an external site (Madrid, 
Spain) : HISPASAT 1-A in September 92. 

Originally designed to perform FDC space mechanics 
tasks related to geostationary positioning, MERCATOR 
flexibility and state of the art man-machine interface 
interested other CNES entities which now use it to 
perform their own tasks : 

-geostationary satellite station keeping: TELECOM 2 
and TDF satellite control centers. 


- TOPEX/DORIS on-board orbit determination 
simulation : TOPEX telemetry files processing, DORIS 
telemetry extraction and treatment (2 Fortran, 3 C and 
3 ADA programs, the MERC ATOR/AD A interface being 
developped in 3 days), on two sites : JPL and CNES 
Toulouse, 

- MEPHISTO experiment, part of United States 
Microgravity Payload (USMP) : telemetry real-time 
acquisition and decommutation for scientists working in 
France. 

Other entities have developped similar data processing 
systems or have similar needs : 

- low eath orbit satellites ground segments, 

- Orbit Computation Center, 

- mini satellites ground segments, 

-for mission analysis purposes (low earth and 
geostationary orbits, interplanetary trajectories), 

- for manned missions. 

So, there are now studies being conducted to develop a 
new and single man-machine interface and data 
processing system likely to meet all the present or future 
requirements related to the space mechanics part of 
ground segments : OREMUS. At the present time, we 
have set up a preliminary list of requirements and 
different solutions based on CNES experience are being 
investigated. 
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